The Difference Between What a Component Does and What We Know It Does

Conventional doctrine holds that specifications are sufficient, complete, static, and homogeneous. For systemlevel specifications, especially for software architectures, conventional doctrine often fails to hold. This can happen when properties other than functionality are critical, when not all properties of interest can be identified in advance, or when the specifications are expensive to create. That is, the conventional doctrine often fails for practical software components. Specifications for real software must be incremental, extensible, and heterogeneous. To support such speci fications, our notations and tools must be able to extend and manipulate structured specifications. In the UniCon architecture description language, we introduce credentials , a property-list form of specification that supports evolving heterogeneous specifications and their use with system-building and analysis tools. Conventional software doctrine calls for component specifications that are: • Sufficient and complete: the specification of a component says everything a user needs to know or is permitted to rely on about how to use the component, • Static: the specification can be written once and frozen, and • Homogeneous: the specification is written in a single notation. For example, a typical discussion of the promise of reuse [Ben95] is introduced,1 Three prerequisites must be met for a component to be used in more than one system: complete, opaque enclosure; complete specification 1Note that this description comes from the applications community, not the formal methods community. of its external interface; and design consistency across all sites of reuse. Without these, reuse will remain an empty promise. It may be possible to adhere to the conventional doctrine for algorithms and data structures, or when functionality is the only property of interest. However, architectural, or system-level, components cannot in practice satisfy these criteria. Indeed, they inevitably will not, and it is impractical to try. This paper is about what this implies and how to cope with it: why architectural specifications are insufficient, incomplete, incremental, and heterogeneous -and how software development methods and tools must adapt in response. Section 1 describes architectural components and explains why they cannot adhere to the conventional doctrine. Section 2 considers many of the properties that need to be specified. Section 3 sets out requirements for architectural specifications. Section 4 introduces an approach to a solution, credentials for those properties that have been specified to date. 1. Architectural components and their specifications Software architecture deals with the overall structure and properties of software systems. The most common architecture description languages (ADLs) support components, connectors, and other aspects of the system such as styles, constraints, or design rationale [ShawGar96, PerWolf92]. Although the issues raised here apply to all architectural elements, this discussion focuses on specifications of the components, which may be either primitive (i.e., written in a programming language) or composite (i.e., defined in the ADL). The information required to use an architectural component goes beyond computational functionality to include structural properties that affect how the component can be composed with other components; extra-functional properties that describe performance, capacity, environmental assumptions, and global properties; and family properties that assert relations among similar or related components. Software development environments should accommodate an open-ended collection of tools for construction and analysis. Different tools may depend on different properties, and some tools may generate new specification information [ICSE95]. Specifications of architectural components are intrinsically incomplete because system correctness depends not only on computational functionality but on other properties as noted above [Shaw85, GAO95]. It’s impractical to expect full specifications of all these properties because of the prohibitive effort required to specify a wide variety of properties, whether or not anyone will use the information. Worse, it’s impossible: the developer cannot anticipate all the aspects of the component that its users might care about. As an added complication, the degree of precision in the specification may be influenced by the tradeoff between the costs and benefits of improved precision [Shaw81]. Although completeness is impractical, it is still appropriate to expect specifications for a common core of properties, and it is reasonable for a tool to require certain properties. Reasoning with partial specifications has already received some attention [Jac94, Per95]. Specifications of architectural components must be extensible , because developers discover new kinds of dependencies as they attempt to reuse independently-developed components together. Even with the best of good faith, component developers cannot describe all the incidental ways their components may interact with the entire environment. Garlan and colleagues analyze the implicit assumptions that interfered with one instance of attempted reuse [GAO95]. Not only is much important information implicit, but users have no effective way to capture information they discover for future reference. As the specifications are extended, information about a property may be received from multiple sources; these must be reconciled [BarWing90]. Specifications of architectural components must be heterogeneous , because of the diversity of significant properties, as described in Section 2. It is unreasonable to expect a single notation to serve for all of them. Thus the drivers of specification incompleteness, extensibility, and heterogeneity are • Open-ended needs: The designer cannot anticipate all properties that may ever be of interest to some user. Further, future users may find new ways to take advantage of old properties. Interesting properties are of many different kinds. • Cost of information: Even for common properties, it is not practical to produce a complete specification. Further, the precision of a specification may be selected to balance the cost of getting a tight bound against how badly it’s needed. The cost of understanding a specification also affects its utility. • Evolution: As time passes, new properties may be added to a specification because someone (not necessarily the developer) discovers new information or new dependencies. Developers can often make progress with partial information but take advantage of additional information. 2. Architectural properties The main reason why architectural components require incomplete, extensible, and heterogeneous specifications is the diversity of facts about a component that may affect a designer’s ability to compose it with other components and achieve a correct and consistent result. This section describes three major classes of properties that augment the conventional functional properties of type, signature, and pre/post conditions. 2.1 Structural properties The most significant properties for architectural design deal with the ways components interact, and hence with the ways those components can be combined into systems. Especially important is the packaging of a component, which includes the type of component and the types of interactions it is prepared to support. The choice of packaging is often largely independent of the underlying functionality, but components must be packaged in compatible ways if they are to work together smoothly. For example, unix provides both a sort system call and a sort filter; although they have the same functionality, they are far from interchangeable. Some common packagings for components and the ways they interact are: Component type Common types of interactions Module Procedure call, data sharing Object Method invocation (dynamically bound procedure call) Filter Data flow Process Message passing, remote procedure call, other communication protocols, synchronization Data file Read, write Database Schema, query language Document Shared representation assumptions Distinctions of this kind are now made informally, often implicitly. If the distinctions were more precise and more explicit, it would be easier to detect and eventually correct incompatibilities by analyzing the system configuration description. Such checking must address not only local compatibility (e.g., do two components expect the same kinds of interactions) but also global properties (e.g., are there loops in a data flow system?). 2.2 Extra-functional properties In addition to functionality and structure, architectural specifications must be capable of expressing extra-functional properties related to performance, capacity, environmental assumptions, and global properties such as reliability and security [MCN92, Shaw85, CBKA95]. Many of these additional properties are qualitative, so they may require different kinds of support from more formal specifications. These other properties include: